Skip to content

feat(resolver): enforce PyPI quarantine check for all resolver types#1102

Open
pavank63 wants to merge 1 commit intopython-wheel-build:mainfrom
pavank63:enforce-quarantine-check-non-pypi-resolvers
Open

feat(resolver): enforce PyPI quarantine check for all resolver types#1102
pavank63 wants to merge 1 commit intopython-wheel-build:mainfrom
pavank63:enforce-quarantine-check-non-pypi-resolvers

Conversation

@pavank63
Copy link
Copy Markdown
Contributor

@pavank63 pavank63 commented May 1, 2026

The PEP 792 quarantine check previously only ran inside get_project_from_pypi(), which is only called by PyPIProvider. Packages resolved via GitHubTagProvider, GitLabTagProvider, or PyPIProvider with a custom index URL bypassed the check entirely.

Add a standalone check_pypi_quarantine_status() function that queries pypi.org for quarantine status and call it unconditionally from both resolve() and resolve_source() entry points. Remove the quarantine check from get_project_from_pypi() to avoid split responsibility.

Closes: #1101

The PEP 792 quarantine check previously only ran inside
get_project_from_pypi(), which is only called by PyPIProvider.
Packages resolved via GitHubTagProvider, GitLabTagProvider, or
PyPIProvider with a custom index URL bypassed the check entirely.

Add a standalone check_pypi_quarantine_status() function that queries
pypi.org for quarantine status and call it unconditionally from both
resolve() and resolve_source() entry points. Remove the quarantine
check from get_project_from_pypi() to avoid split responsibility.

Signed-off-by: Pavan Kalyan Reddy Cherupally <pcherupa@redhat.com>
Co-Authored-By: Claude <claude@anthropic.com>
@pavank63 pavank63 requested a review from a team as a code owner May 1, 2026 14:04
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 1, 2026

📝 Walkthrough

Walkthrough

The changes extract PyPI quarantine status checking (PEP 792) into a standalone check_pypi_quarantine_status() function that queries the PyPI JSON API and raises ValueError if a project is quarantined. This function is now called unconditionally from both resolve() and resolve_source() entry points, ensuring quarantine validation occurs regardless of which resolver provider is used (PyPI, GitHub, GitLab, etc.). The original quarantine check is removed from get_project_from_pypi(), leaving only logging for non-fatal fetch errors.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: adding a standalone quarantine check function that runs for all resolver types, moving it from PyPIProvider-only scope.
Linked Issues check ✅ Passed The PR implements Option A from issue #1101: adds check_pypi_quarantine_status() function, calls it unconditionally from resolve() and resolve_source() entry points, and removes the check from get_project_from_pypi().
Out of Scope Changes check ✅ Passed All changes are directly in scope: new quarantine check function, integration into both resolve entry points, removal from get_project_from_pypi(), and comprehensive unit tests with fixtures.
Description check ✅ Passed The pull request description clearly explains the problem (quarantine check bypassed for non-PyPI providers), the solution (standalone check_pypi_quarantine_status function called unconditionally), and references the closed issue #1101.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@mergify mergify Bot added the ci label May 1, 2026
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/fromager/resolver.py (1)

377-397: 💤 Low value

QUARANTINED falls through to catch-all, logging misleading "unknown status" warning.

If get_project_from_pypi queries PyPI directly (not via entry points) or if a custom index mirrors PyPI's quarantine status, QUARANTINED hits case _: and logs as "unknown status." Add explicit handling:

♻️ Suggested fix
         case pypi_simple.ProjectStatus.DEPRECATED | pypi_simple.ProjectStatus.ARCHIVED:
             logger.warning(
                 "project %r is no longer active: %r: %s",
                 project,
                 package.status,
                 package.status_reason,
             )
+        case pypi_simple.ProjectStatus.QUARANTINED:
+            # Quarantine is enforced at resolution entry points (resolve/resolve_source).
+            # If we reach here, the check either passed or was bypassed.
+            logger.debug(
+                "project %r has quarantine status in index response (checked at entry point)",
+                project,
+            )
         case _:
             logger.warning(
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/fromager/resolver.py` around lines 377 - 397, The match on package.status
in get_project_from_pypi currently falls through QUARANTINED to the catch-all
and logs "unknown status"; add an explicit case for
pypi_simple.ProjectStatus.QUARANTINED in the match block (near the existing
cases for ACTIVE, DEPRECATED, ARCHIVED) and log a clear warning (e.g., "project
%r is quarantined: %s") using project and package.status_reason so quarantined
packages are not misreported as unknown; keep check_pypi_quarantine_status
semantics unchanged at the resolution entry points.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/fromager/resolver.py`:
- Around line 377-397: The match on package.status in get_project_from_pypi
currently falls through QUARANTINED to the catch-all and logs "unknown status";
add an explicit case for pypi_simple.ProjectStatus.QUARANTINED in the match
block (near the existing cases for ACTIVE, DEPRECATED, ARCHIVED) and log a clear
warning (e.g., "project %r is quarantined: %s") using project and
package.status_reason so quarantined packages are not misreported as unknown;
keep check_pypi_quarantine_status semantics unchanged at the resolution entry
points.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 72cf8f67-18ca-4c6c-8848-8044e83d0c4d

📥 Commits

Reviewing files that changed from the base of the PR and between 06e6317 and 445f9b6.

📒 Files selected for processing (3)
  • src/fromager/resolver.py
  • src/fromager/sources.py
  • tests/test_resolver.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Enforce PyPI quarantine check for non-PyPI resolvers (GitHub/GitLab)

1 participant